The present invention relates in general to the field of computers and similar technologies, and in particular to software utilized in this field.
A useful feature of Object Oriented Programming (OOP) is its modular nature and its ability to use and re-use objects from a producer's library. Thus, OOP allows a user to write an OOP program that makes a call to a library of objects, which has been created by a producer such as a third party class code provider. One feature of objects and classes, including those in the producer's library, is their ability to interface with other code, including other objects/classes, operating systems, etc. Code that controls and coordinates this interface is known as an Application Program Interface (API), which includes control routines, protocols, etc. required to interface with a particular object/class.
When object code changes (has a class or method renamed, is moved to another package, or is otherwise updated or modified in a process known as “refactoring”), API's that are attendant to (associated with) the changed object code are often also changed. For example, assume that a class is modified to change its name from “OldName” to “NewName.” Thereafter, any code that previously was written to make a call to the class “OldName” (via an API for “OldName”) must be modified to call the class “NewName.” While current compilers will usually cause these name changes to be automatically corrected and promulgated throughout the source code in a workplace in an Integrated Development Environment (IDE), the user is forced to review the entire process, usually in a modal dialog. Thus, the user's code cannot be compiled until after all of the changes (e.g., replacing “OldName” with “NewName”) have been made. This results in the condition that the changes cannot be processed individually to see the effects of each API change, such that there cannot be a scoping of the application for changes, and thus the review process is not scalable. 